From the point of view of a developer who wishes to create software for a particular electronic system, it is highly desirable to have complete and fully verified documentation and collateral information of register information available to them as early as possible. Missing or incorrect information may lead to expensive trials, errors and development iterations which may further result in significant productivity loss. Trials are only possible with existing real hardware and software development cannot be completed until the hardware is defined. A known method for allowing early verification of software is the generation of reference models where a simulator enables the execution of software by more abstract version of the underlying hardware. This method is complex and difficult to automate. Another known electronic design methodology is the so-called Electronic System Level (ESL) design and verification. This approach focusses on top-down methods and does not take into account the usage of existing intellectual property (IP) blocks as building blocks.
Registers are an essential piece of any electronic system, for multiple reasons: they are the interface implementing the communication between the hardware blocks of such a system and the software being executed by this system. Besides that, registers control the functionality of the hardware blocks and provide or exchange the data used by the functionality implemented by these hardware blocks. In many cases, every register implemented within a hardware block may have a different register layout composed of multiple fields, for example, for allowing the recording of a single control bit or bit flag or multi-bit fields, thereby enabling the storage of data or multiple selections. The sheer amount of registers and fields implemented within registers is one of the issues for hardware verification and embedded software. Even simple electronic systems can have more than one hundred building blocks, each of those building blocks may employ registers, sometimes only a few but sometimes also significantly more than one thousand registers. Complex systems may have several hundreds of building blocks, and millions of registers and register fields. The task to document, verify and/or validate such registers or to create software for controlling the underlying hardware via those registers is one of the very complex tasks which need to be performed. One larger problem is the variability of those registers, caused by inclusion of different versions of an IP block, the large amount of parameterization possible within those IP blocks and the impact of hardware synthesis and connectivity on the register space. A result of the complexity and variability is that the identification and documentation of the actually implemented registers and register fields within an electronic system is of prime importance. This makes a complete, correct and consistent documentation of all registers and register fields within an electronic system an essential deliverable that needs to be provided as quickly as possible. The same is true for all collateral information related to registers and register fields; e.g. “header files” used by software compiler tools, control data used by software debugging tools, or other reference data needed by hardware debuggers or simulation environments. Any missing, incorrect, or invalid register or register field within such a document or collateral data might result in erroneous software implemented and thus causing a failure of the overall electronic system.
A reference manual for a typical electronic system may consist of several thousand pages and so creating such a document is time-consuming and complex. When creating such documents, it is preferable to ensure the usage of correct and complete information and that the document is kept up-to-date to reflect any changes made to the design database relating to the electronic system. Otherwise, documentation may contain only generic information which describes a superset of possibly-implemented registers and which is not tailored to the actual parameterisation of the various blocks that may comprise the electronic system. It may also quickly become outdated when changes to the hardware are not reflected in a timely fashion. The known IP-XACT standard defines an XML schema which describes electronic components and their designs to enable automated configuration and integration through tools. As registers are part of electronic components, the standard also enables the capture and exchange of related information and the use of this information by tools for further processing. However, IP-XACT and other interface standards do have their limitations as they generate the hardware blocks and the related verification data out of the same source. Another drawback is that parameterisation capabilities of IP-XACT and other related languages do not match the parameterisation capabilities of hardware description languages
Therefore, there is a need for accurate and up-to-date documentation and collateral information, and particularly register information, which at least mitigates some of the disadvantages of the known systems.